Since its inception in 1995, the Java programming language has become increasingly popular. Java, which is an interpreted language, enabled the creation of applications which could be run on a wide variety of platforms. This ability to function across a variety of different client platforms and Java's relatively easy implementation of network applications has resulted in its use in endeavors as basic as personal webpages to endeavors as complex as large business-to-business enterprise systems.
As Java has become more commonplace, a wide variety of tools and development platforms have been created to assist developers in the creation and implementation of Java applications. These development platforms have usually been built around an application server program which provides a common interface for accessing internal data and resources.
However, as these servers and their associated applications have become more complex and developed there has been a corresponding need to properly configure resources so that they can be accessed by the applications. Often, features such as Java Database Binding Connectivity (JDBC), which governs application access to internal data sources and Java Messaging System (JMS), which controls messaging among and between applications must be separately configured on the server before the application can be deployed. This greatly complicates the process of deploying applications on new servers.
FIG. 1 illustrates an embodiment of an application environment as practiced in the prior art. A server 120 supports multiple java applications 105, 110, and coordinates access to an internal database 145. The server 120 performs platform functions such as resource management, messaging, load balancing, and access to data sources. The server includes a deployment mechanism that deploys the applications 105, 110 from stored archive files.
The internal databases 145 are information sources that are accessed and utilized by the server 120. In one embodiment, the internal databases 145 are Structured Query Language (SQL) compliant databases. The server 120 receives requests for data from the applications 105, 110, translates the data requests to SQL requests, and then passes the requested data back to the applications.
The applications 105, 110 are groups of modules that have been assembled into application units for use on the server 120. The applications are configured to provide interaction with remote entities and to provide a mechanism by which the server interacts with clients and other servers.
The server 120 includes JMS configuration 130. The JMS configuration sets the parameters through which messaging is performed between and among the different applications 105, 110. The JMS configuration 130 includes information such as a store indicating where persistent JMS data is stored, a paging store indicating where non-persistent JMS data is stored, a template for any queues or topics for the server, and any other configuration information that is necessary to implement messaging operations within and among the applications 105, 110. In one embodiment, the JMS configuration 130 is set by a system administrator and must be properly configured before the applications 105, 110 can utilize messaging.
The server 120 also includes JDBC 140 configuration. The JDBC configuration includes connection pool characteristics, driver information, tracking information, and information about the types and sources of data, such as the internal databases 145, that are accessed. In one embodiment, the JDBC configuration 140 is set by a system administrator and must be properly configured before the applications 105, 110 can access the internal databases 145. This process can be especially time consuming and difficult, significantly adding to the cost of deploying applications.
What is needed is a method of creating applications that can utilize messaging and database functions without the need for additional server configuration.